IN THE SPECIFICATION: 



i 



Kindly amend the specification as noted below: 

At page 4, lines 7-14: 

In this conventional pipeline method, the first packet, Packet 1, is 
processed through Processor 1. As soon as Packet 1 completes the 
first phase of processing and moves on to Phase 2, the second packet, 
Packet 2, can start being processed using Proc e s s orl Processor 1 . In 
one embodiment, in order for this pipeline approach to work smoothly, 
each phase of the processing must be allocated an equal amount of 
time. If, as above, "M" is the maximum tolerable time within which a 
packet must be completely processed, each of these phases can be 
allocated no more than a time of "M" divided by the number of phases. 
In the case described in Fig. 2, each phase can be allocated no more 
time than M/5. 

At page 7, lines 3 through 12: 

For instance, in processing data packets in a network in one 
embodiment of the present invention, it may be desirable to ensure that 
packets in the same micro-flow (e.g., a specific transmission between a 
source and a destination node on a network) maintain their order. In 
one embodiment, pre-processing comprises performing a pre-hash on 
all of the packets that currently are being processed, and storing this 
information. The pre-hash then is performed on any incoming packet, 
and this pre-hash is compared to the stored information. If the hash on 
an incoming packet is the same as the hash on any of the packets that 
currently are being processed, it is assumed that the incoming packet 
belongs to the same flow as another packet currently being processed. 
In such a situation, processing on the incoming packet only is started 
when it is ascertained that no packet in the same micro-flow currently 
is being processed. 
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At page 9, line 12 to page 10 5 line 6: 

The data field 312 can include a portion of or the entire content of the 
received data packet. This content can include a header (e.g., an IP 
header information) and data information associated with the received 
data packet. The label field 305 is responsible for enabling the 
network to differentiate the data packets of one micro-flow from the 
data packets of another micro-flow. In addition, the label field 305 is 
responsible for associating each micro-flow data packet with 
quantified QoS characteristics. This label field 305 specifically can 
represent a uniquely identifiable set of variables relating to the OSI 
model network layer (e.g., IPv4, IPv6) and transport layer (e.g., TCP, 
UDP) characteristics of the data packets of a single micro-flow. In one 
embodiment, the variables that are used to uniquely identify one 
micro-flow from another includes the protocol type, the source 
address, the destination address, the TCP/UDP source port number and 
the TCP/UDP destination port number associated with each data 
packet of the micro-flow. It should be noted that depending upon the 
type of data packet that is received by a switch, the information that is 
used to differentiate data packets of one micro-flow from another can 
be other types of information, such as the real time protocol ("RTP") 
type, MPLS or DiffServ identifiers, other information relating to a 
characteristic that is unique to the data packets of a specific micro- 
flow or a combination of this information. For further details 
regarding micro-flows, please refer to cop e nding US co-pending U.S. 
Patent Application No. 09/552,278 (now U.S. Patent No. 6.574.195). 
entitled "Micro-Flow Management," which is hereby incorporated by 
reference herein. 
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